Great work. This got my platformIO build working. Thank you.

No problem! I'm still waiting on a programmer, but I think that it works the same as the original. I'm hoping to add the ability to provide an endstop signal from the stepper board. Do you think it would be useful to you @robtheminnie ?

sensorless homing is not hard to implement. In one branch of my fork the LED is blinking on "endstop" triggered based on angle deviation.
Adding pulling one of the pins on the header low or high and the testing can start. ;)

@Quas7 so basically you used one of the programming pins for the SWD interface? And from your comments you put the init statement into the function that activates it so you can program it without resetting it each time? It seems like a good idea. I was going to add the possibility of having the sensorless homing done by looking at how long the motor was unable to lower past the desired error. What do you think? I know we have different versions, but I think that we could probably make a community project both the version if BTT doesn't want to accept our changes

as this hardware platform is flawed by design (see the longest issue) I personally do not invest any more time into it until it is fixed. v2 seems not to address the basic issues either.

In my humble opinion, the MKS 42B is the most thought throu of the china clones of the original misfit design.

But in regards to your idea, just setting the angular deviation trigger to a reasonable value is not much different than waiting a certain time a certain speed for the deviation to build up. Homing slowly would be needed in both ways as we can not read the back field current of the motor as TMCs can do.

and maybe before you start from BTT code base take a look at Jans fork. He has to biggest rework of the BTT code in his 'truestep' project and would be my starting point of anything new for this.

Yeah, I'm just working with the S42B v2, so I'll have to check out Jans fork. Maybe he'd be interested in working on a joint project that would allow both of the boards to be programmed with basically the same code (some minor exceptions).

as this hardware platform is flawed by design (see the longest issue) I personally do not invest any more time into it until it is fixed. v2 seems not to address the basic issues either.

In my humble opinion, the MKS 42B is the most thought throu of the china clones of the original misfit design.

But in regards to your idea, just setting the angular deviation trigger to a reasonable value is not much different than waiting a certain time a certain speed for the deviation to build up. Homing slowly would be needed in both ways as we can not read the back field current of the motor as TMCs can do.

@Quas7, Why do you say the BTT design is flawed? Im not familiar with the misfit version, so cannot really comment. Just curious to hear your thoughts.

@robtheminnie
Because they just omitted all blocking capacitors on the 3V3 rail. Datasheet recommendations for the STM32 as well as the TLE and OLED are quite clear on that topic but well... all documented in this issue for the v1: bigtreetech/BIGTREETECH-S42B-V1.0#16
Just read the last 10 entries - the rest was shooting in the dark for a later quite obvious design flaw.

v2 seems to have the same flaw although they optimized the layout a bit - might help but still not best practise, IMHO.

@CAP1Sup
I think, you might be interessted in this discussion over here: bigtreetech/BIGTREETECH-S42B-V1.0#17
And before you start to program the board glance over this: bigtreetech/BIGTREETECH-S42B-V1.0#3 (comment)
I think, also for the v2 it is better not to enable the motor before and during programming.

Interesting to know. Thanks for the info. I'm not an electronics guy , so that sort of thing is beyond my knowledge. I'm software and hardware really.
As an aside, it strikes me that servo motor control actually isn't that useful in the world of 3d printing (which is my use case, i don't know about you guys) but actually the attraction is avoiding layer shift. So what about a monitoring mechanism to detect a 'step request' from the main board and then indicate to the main board if a step has been skipped/missed, and to request another step. After X steps missed abort print to save time and material.
Thoughts...?

Interesting to know @Quas7 . I haven't had any issues with my v2. Thanks for your advice! I'll try to make the best with what I have.

@robtheminnie the "position error e-stop" is a common feature for CNC mills.
Most industrial hybrid stepper motors have therefore an output for this, e.g. JMC iHSSXX series via the Alarm pins that you just route to an endstop- or pause-pin. But there are many different and you can get these below 100€/pcs as well.
https://www.upload.sorotec.de/doku/manuals/DS_iHSS57+iHSS60en_190509_Soro.pdf

The feature itself is not hard to implement, as long as you only connect to an endstop pin and make the endstop always-active in whatever 3d printer firmware you have. But one should make an XY-homing and not keep the hot nozzle on top of the print if the endstop is triggered - not directly sure, how to do that.

More complicated is resending steps after they have been lost. This would require an adaptation of the 3d printer firmware and would impact the motion planning part - that is far from trivial and the limited number of devs that know the details normally do not want to mess with that core module, afaik. Also it is not easy to stop and revise the command queue in the motion buffer without top-speed penalties.
The normal argument against things like that for 3D printers is normally, that a well tuned 3d printer with decent hardware will never lose a step in contrast to a CNC where loads can vary quite much from cut to cut and breaking an endmill easily sets you back 50€ or more not mentioning the ruined stock costs.
And the other problem is, that if you start losing steps because of collisions (e.g. PETG blobs because of missing nozzlecovering silicone sock or at least Kapton cover) there is a chance you popped off the model from the bed as well. ;P

But, this is only my view - feel free to share your idea e.g. with the Marlin devs (or first check the closed issues for that feature) :)

@CAP1Sup I built this today i have a STlink so i can try to flash it tonight, I notice the binary that is output is is about 20kb smaller then the precompiled one they include.

At any rate ive started watching your repo As it would be great to get treuestep features working on the V2.0

@GhostlyCrowd I was doing some testing and it appeared to be running a little slower. I’m not sure what caused it or if I’m just not remembering the speed of the original LVD updates correctly. I have a second board that is unmodified, so I’m going to do some testing to see if there is a difference and if that difference actually affects anything. It really shouldn’t, but my printer is torn apart so I can’t do full print testing. I’d love to hear from you as to how it’s going. As long as the changes I made previously don’t have a significant performance impact, I’ll try to add the TrueStep functionality this weekend if I get the chance.

@CAP1Sup I havnt got them installed on anything yet, I'm going to dump the original firmware first for archive purposes. and fiddle with them on a spare mega/ramps before i put them on a production rig.

@CAP1Sup forgot to mention the developer of TrueStep expressed interest in V2.0 support but a lack of time. Maybe you guys can put your heads together. He mentions it here in a reply to one of my comments bigtreetech/BIGTREETECH-S42B-V1.0#11 (comment)

@GhostlyCrowd for future reference, you can edit the comments just in case you missed something. Just a tip. I will have to check out the changes he has made and see how they would work with the v2 code. Thanks for the info!

@CAP1Sup yeah, mobile is a pain in the butt to edit sometimes. I havnt flashed tonight because i can't get the two S42B V2.0 i got to work properly out of the box, neither will calibrate, so naturally it does nothing it's supposed to. they work fine in open loop though....

I might just flash them see if anything changes and if not guess i got to send them back :(

Sounds good. Maybe check the spacing between the rear chip and the magnet? @GhostlyCrowd

I accidentally shipped my ST-Link across the country with a printer i modified for a client so I'm waiting on that. Still no change in my issue. Its seeing the magnet. if i remove it the red light flashes 10 times which according to their documents means magnet missing or misaligned. Is there any way i can delete the cached calibration and see if that helps. Via serial?

Well, a programmer would be best. Looking at the code, you can’t erase the settings with factory firmware. I’m thinking that you might have an issue with your mounting, but if you’ve checked it then... I don’t know. Maybe faulty components? Could you try a different motor? @GhostlyCrowd

Well, a programmer would be best. Looking at the code, you can’t erase the settings with factory firmware. I’m thinking that you might have an issue with your mounting, but if you’ve checked it then... I don’t know. Maybe faulty components? Could you try a different motor? @GhostlyCrowd

Ive tried a few different steppers and both of the BTT S42B V2.0's I have, exabit the exact same issues, I'm convinced its a firmware issue its pretty curious that Dip 3 on it just acts like its in open loop still. If i remove the magnet i get the 10 red led flash that is expected and if i click calibration with out the magnet i get a red flash again. with the magnet in i get no red led so it is seeing them magnet. I just cant calibrate the damn thing.

You mentioned there is no factory reset in the code, would this be addable? might prove to be useful later.

New ST-Link should be here tomorrow and I will back up the full chip, then wipe it then do a flash which should start me off fresh.

maybe you checkout the "magnetic compatibility" issue in the v1 project. Not every motor is straight forward working.

maybe you checkout the "magnetic compatibility" issue in the v1 project. Not every motor is straight forward working.

I've seen that earlier. None of my motors seem to leak magnetic field frim the internals the backside is beefy on them. I even have Creality Ender 3 steppers laying around that i tried that are "known working" as they have a full setup guide and include screws for these exact steppers. Still my issues persist. :(

@GhostlyCrowd hopefully you’re able to get your problem fixed. I’m going to check out adding that functionality to the LCD in the future, just have other things going on currently.

@CAP1Sup for your reference as well THIS is the answer. GOD BTT's documentations SUCKS now the questions are what dips do what.
bigtreetech/BIGTREETECH-S42B-V1.0#43 (comment)

Also i compiled the 2.0 firmware you fixed, and have flashed it so far its calibrating with Dips 1+2 on and 3+4 off. It would not calibrate with Dip 4 on and 1-3 off.

EDIT, I think the Dip switch is mounted backwards. 1 seems to be 4 and 4 seems to be 1. Dip 1 on 2.3 and 4 off its calibrating.

Edit 2: the compiled firmware doesn't seem to be the same as what was shipped on it, the calibration is so SLOW and the Stepper whines badly on the firmware I compiled from source. I'm running the same test on the firmware that came with it its much quieter. Also get a lot of LCD noise and no longer get any serial output on s42b boot with the compiled form source firmware. So i have a feeling the source they posted isn't what they used for production shipment.

@GhostlyCrowd I think that they did something with the main loop to make it faster. I'm not sure what, but it's something that we're going to have to investigate. The current performance of the compiled firmware is complete garbage, let's be honest. I think the first thing I'll shoot to fix is the issue with the terrible performance, then move to working with TrueStep and sensorless homing.

As for the dip switch labeling, I can help to tell you what they do as per the code as soon as I get the new code running smoothly

@GhostlyCrowd I think that they did something with the main loop to make it faster. I'm not sure what, but it's something that we're going to have to investigate. The current performance of the compiled firmware is complete garbage, let's be honest. I think the first thing I'll shoot to fix is the issue with the terrible performance, then move to working with TrueStep and sensorless homing.

I'm glad my lack of experience with code wasn't the flaw in this test, and you see it too. The firmware from the source is total trash. "Working" I guess... but the steppers sing badly, movement seems choppy and calibration takes a very long time. I timed it at almost 10 minutes.

Whereas the firmware shipped on the device has none of the above issues at the very least. Aside from the stepper noise being tolerable, the calibration takes about 130 seconds opposed to 10 minutes, as an example.

I Really appreciate you working on the V2 firmware, and your support, I emailed BTT days ago, and you have been more of a help than they have, they have not even replied, yet... The platform is new but shortly many people are going to join my appreciation for your work on it.

@GhostlyCrowd thanks for the inspiring words. I'm thinking that it's an issue with the one of the interrupts. The interrupt is timed, so it is interfering with the normal function of the motor. That singing is most likely because the motor is not being moved smoothly (or power controlled smoothly), due to the fact that it can't see the motor movements through before being interrupted. There isn't a reason that I can see as of now that there would be an interrupt other than the step pin, the buttons, and the receive pin. Like I said, thanks for the inspiring words. I currently have a project ongoing for my Robotics team, but I will attempt to make some time to look over this code.

@GhostlyCrowd I fixed all of the performance issues. I was able to overclock the CPU, meaning that I could actually get it to run faster than stock. Perhaps maybe it runs a bit too fast now... but at least I got it working. They had dormant code to do this, so I think that this is how they were able to achieve the faster performance. I rewrote the overclocking code to use nice definitions instead of the raw bitsetting that they use. With that, I think that the performance issue is solved permanently.

Edit: Now there's issues with moving the motor, so now there's that.

@GhostlyCrowd I fixed all of the performance issues. I was able to overclock the CPU, meaning that I could actually get it to run faster than stock. Perhaps maybe it runs a bit too fast now... but at least I got it working. They had dormant code to do this, so I think that this is how they were able to achieve the faster performance. I rewrote the overclocking code to use nice definitions instead of the raw bitsetting that they use. With that, I think that the performance issue is solved permanently.

Edit: Now there's issues with moving the motor, so now there's that.

I can flash it tonight I pulled your changes already. See if it reacts the same as the Shipped firmware. I'm kind of surprised you had to overclock the MCU I thought it was 72MHz stock which is already almost 2x the speed of the previous MCU on the 1.0 and 1.1 drivers.

I'll see what kind of issues I have tonight in my testing and report back.

I see on your repo there isn't an issue track so we cant really post what we find. So want to keep it here for the time being?

@GhostlyCrowd sounds good. Like I said, I think that it was factory overclocked to 72 MHz, so that's why we we're seeing the same results with the new code. Sounds good on the testing, I'd love to hear how it goes. I didn't realize that issues were disabled by default, so I enabled them. It'll be much nicer for future to list the issues there if you wouldn't mind. As for the stepping issue, I really don't know how I'm going to fix it. I'll take a look at some other code online to see if I can figure out how they are calculating and executing the rotations. All of the variables related are like "s", which is completely useless so I guess I'll try to rewrite them so that they make more sense.